 \chapter{System Overview}
\label{cha:overview}

%Briefly introduce the system and its components. Later chapters go into more detail.

SimSpark is built upon an application framework called zeitgeist. This
framework provides basic OS abstractions like file and archive
support, logging, shared libraries etc.), a scripting interface to
Ruby and a powerful plugin mechanism coupled with an object hierary
that provides a unified namespace. This library is the backbone of the
system.

Zeitgeist allows us to load new classes at runtime from plugins and
install object instances in a hierarchy. We can locate these instances
via path expression just like files in a file system. At various well
known locations are objects called servers that provide services to
other parts of the system. The script server that provides an
interface to the Ruby ist installed at \texttt{/sys/server/script}.

Built as part of this object hierarchy is a scene graph that the
system uses to represent the simulated world. This scene graph and
related concepts are managed within the next layer of the system, that
we call oxygen. It provides classes that encapsulate concepts like
transformations, basic geometric primitives, physical bodies and
collision primitives. It further provides access to a rigid body
physical simulation.

The oxygen library further implements basic simulation services like
agent management and a monitor framework. It is responsible to keep
track and to update connected agents and monitor processes. Last but
not least it provides a customizable run loop service. This service is
implemented as an abstract run loop that is extended with plugins as
needed. In parts of the system can be replaced or left out easily as
for example rendering or monitor support.

The Visualization of the scene and input event processing services are
provided by the kerosin library. It implements the infrastructure for
rendering and device management. Concrete implementations are again
provided by plugins. This allows the simulation to use different back
ends or graphic engine. A default set of plugins utilizes plain OpenGL
and the SDL library.

\section{The Server}

The SimSpark server hosts the simulation process that manages the
simulation. It is responsible to advance the simulation, i.e. modify
the simulation state in a continuous run loop.

Objects in the scene change their state, i.e. one ore more of their
properties like position, speed or angular velocity changes due to
several influences. They are under the control of a rigid body
physical simulation, that resolves collisions, applies drag, gravity
etc. Agents that take part in the simulation also modify objects with
the help of their effectors.

Another responsibility of the server is to keep track of connected
agent processes. Each simulation cycle the server collects and reports
sensor information for each of the sensors of all connected agents. It
further carries out received action sequences that an agent triggers
using its available effectors.

Depending on the setup of the server it renders the simulation itself,
i.e. it implements an internal monitor that omits the network overhead
or it manages and updates remote monitor processes. In the latter
configuration the rendering of the scene is deferred to remote
processes.

\section{The Monitor and Logplayer}

The SimSpark monitor is responsible to render the current
simulation. It connects to a runing server instance from which it
continuously receives a stream of update data that describes the
simulation states either in full or as incremental updates relative to
the preceding state.

The format of the data stream that the server sends to the monitor is
called \texttt{monitor format}. It is a customizable language used to
describe the simulation state. 

Apart from describing the pure simulation state each monitor format
may provide a mechanism to transfer additional game specific
state. For the soccer simulation this means for example current play
mode and goals scored so far.

The monitor client itself only renders the pure scene and defers the
rendering of the game state to plugins. These plugins are intended to
parse the game state and display it as an overlay, e.g. print out
playmode and scores on screen.

The monitor can further be configured to read a protocol of scene
updates from a file and act as a \texttt{logplayer}. In this mode it
does not connect to a server instance but replays an recorded
game. The format of the logfile is identical to the monitor protocol
used on the network.

\section{The Sample Client}

SimSpark provides a simple agent implementation that demonstrate how
to interact with the server. It demonstrates how to connect to the
server, how to read perceptor values and how to use effectors. The
demo behaviour of the agent is implemented as a plugin that can be
replaced in order to customize it for different
simulations. \footnote{A repository of agent implementations from
previous Robocups is available at
\url{http://www.uni-koblenz.de/~murray/robocup/rc07/Binaries/binaries_3D.html}}

\section{Available Simulations}

SimSpark currently provides two version of robotic soccer. There is a
sphere based older version that is available up to version
\texttt{rcssserver3d-0.5.2}. In this soccer version the agents on the
soccer field were simple rolling spheres. 

This soccer simulation was the first step away from its two
dimensional predecessor simulation into a three dimensional
world. Since then SimSpark progressed to a more realistic form of the
soccer game. In recent versions players possess articulated bodies
that resemble humanoid robots.

%\section{Available Robot Models}

%NEC Papero Roboter  Joschka
%Fabio Della Libera models the VStone VisiON 4g
%CITIZEN Eco-B!
%HOAP-2
%'Vierbeiner' von Oli
%Aibo via RosImporter ;)

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "user-manual"
%%% End: 
